Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@backend/internal/bootstrap/bootstrap.go`:
- Around line 139-146: The StreamProducer created from streams.NewProducer() in
the bootstrap code owns a Redis client with a Close() method but is never closed
during graceful shutdown, causing a connection leak. The usecase.StreamProducer
interface only exposes the Publish method, preventing callers from closing the
resource. Add a Close() error method to the usecase.StreamProducer interface to
make the close operation part of the contract, then update the concrete
implementation in streams/producer.go to implement this method if not already
present, and finally invoke streamProducer.Close() in cmd/api/main.go during the
graceful shutdown sequence alongside the existing cleanup of Cache and Enqueuer
resources.

In `@backend/internal/domain/pagination.go`:
- Around line 19-36: The Offset() method can return a negative value when Page
is 0 because the binding constraint allows min=0, but pagination pages should
start at 1. Guard the Offset() method to ensure it handles unnormalized input by
applying the same default normalization logic that Defaults() uses, ensuring
Page is treated as at least 1 when calculating the offset value, so callers get
a valid result even if they forget to call Defaults() first.

In
`@backend/internal/infrastructure/database/migrations/20260623063851_add_user_profile.sql`:
- Around line 2-8: The firebase_uid column is currently nullable but serves as
the identity key, which violates the contract expected by the new API handler.
Add NOT NULL constraint to the firebase_uid column definition in the ALTER TABLE
users statement. Additionally, the separate CREATE UNIQUE INDEX statement on
firebase_uid is redundant since the column already has a UNIQUE constraint;
remove this index creation line. Before applying the NOT NULL constraint, ensure
any existing rows in the users table are backfilled with firebase_uid values to
prevent migration failures.

In `@backend/internal/infrastructure/queue/handlers.go`:
- Line 24: The SendWelcomeEmail method call in handlers.go is passing p.Email
for both the toEmail and toName parameters, which means the welcome email will
address the recipient by their email address instead of a proper display name.
To fix this, extend the WelcomeEmailPayload struct (from tasks.go) to include a
display name field, propagate this name through the upstream UserCreatedEvent,
and then use this display name when calling SendWelcomeEmail instead of passing
p.Email twice. If a display name is not available, at minimum document and
confirm that using the email address as a fallback for the recipient's name is
the intended behavior.

In `@backend/internal/infrastructure/ws/client.go`:
- Around line 65-72: The code currently silently ignores json.Unmarshal errors
when processing inbound WebSocket frames. When jsonErr is not nil in the
json.Unmarshal call on the Envelope type, no logging or error handling occurs
and the frame is dropped without any signal. Add an else block or separate error
handling path after the json.Unmarshal of the Envelope to log the error using
slog.Warn or slog.Error when unmarshaling fails, and continue processing
subsequent messages rather than silently swallowing the error.

In `@backend/internal/infrastructure/ws/hub.go`:
- Line 77: In the hub.go file where fn is being invoked with
context.Background() on line 77, replace context.Background() with the hub's
lifecycle context. This ensures that when the hub's Run method is cancelled, the
context passed to handler fn will also be cancelled, allowing handlers to
properly terminate instead of continuing to run. Use the context that is
associated with the hub's lifecycle (typically a context that is cancelled when
the hub stops running).
- Around line 75-80: The inbound handler in the hub spawns an unbounded
goroutine for each inbound message received, which can cause memory exhaustion
under bursty traffic. Replace the unbounded `go func(msg InboundMessage)`
goroutine launch with a bounded concurrency mechanism, such as a semaphore
channel or worker pool pattern, to limit the maximum number of concurrent
inbound handler executions. Ensure the error handling and logging behavior
within the fn(context.Background(), msg) call remains intact while enforcing the
concurrency limit.

In `@backend/internal/server/server.go`:
- Around line 65-84: The Redis Streams consumer goroutine has two issues that
need fixing. First, replace context.Background() in the consumer.Run call with a
cancellable context that is tied to the server lifecycle (similar to the
workerCancel pattern used in main.go), and ensure this context is cancelled
during graceful shutdown so that the Run method returns and allows the
consumer.Close() call to execute. Second, the error returned from
streams.NewConsumer at line 67 is silently discarded via the if err == nil guard
- instead log this error so that failed consumer setup is observable to
operators, following the guideline to never swallow errors.

In `@backend/internal/transport/handlers/fcm_handler.go`:
- Around line 54-59: The error returned by the streamProducer.Publish call in
the FCM handler is being silently discarded using the blank identifier. Instead
of ignoring the error with `_`, capture the error returned by
streamProducer.Publish when publishing the UserCreatedEvent and log it using an
appropriate logger at the error level. This ensures that any failures in the
publish operation are observable and can be debugged, while still allowing the
request to proceed as a best-effort operation.

In `@backend/internal/transport/handlers/validation.go`:
- Around line 11-13: The error handling in the ShouldBindJSON validation block
is exposing internal validation details by using err.Error() directly, which
violates the error-handling principle of never exposing internal error messages
to clients. Replace the err.Error() call with a stable, client-facing message
such as "invalid request body" in the JSON response to prevent leaking internal
details like field names and struct tags while still informing the client that
their request was malformed.

---

Nitpick comments:
In `@backend/internal/infrastructure/queue/handlers_test.go`:
- Around line 13-23: The current test TestHandleWelcomeEmail_ValidPayload only
verifies behavior with a nil sender, so the actual email sending path through
sender.SendWelcomeEmail(...) is never exercised. Add a second test that
constructs the handler with a mock or test double that implements EmailSender,
then verify that the mock's SendWelcomeEmail method is called exactly once with
the expected arguments (p.Email for both the email and display name parameters
from the WelcomeEmailPayload).